A food court is a collection of food vendors, typically found in shopping malls, airports, and other high-traffic locations. These vendors offer a variety of food options, including fast food, ethnic cuisine, and specialty items such as desserts and beverages. Food courts are designed to provide customers with a convenient and efficient way to grab a quick meal or snack while on the go. They often feature a seating area for customers to enjoy their food and may also have amenities such as free Wi-Fi and charging stations.

The question now lies in, what configuration is more efficient?

Choping

To chope is to book a table or queue for a table to be available. This behaviour is typically borne of a forward thinking consumer who wishes to secure the future of their dining experience. Additionally, this behaviour is typically expectandly borne out of prior experience in having had to wait laborious hours for tables in one’s lifetime.

Not choping

The bolder approach to one’s dining experience. This is characterized by one queueing for food directly, prioritizing acquisition over reconciliation.

Efficiency

Efficiency in a food court setting, can be interpreted in a number of ways. We decided to categorise them based off of

potentially crucial recordable metrics in this operation were hinted by the illustrated scenario. These metrics included but were not limited to:

Gaussian variables

  • FoodCourt Metrics
    • Cooking Time
      • Normally distributed
      • Stall dependent
    • Eating Time
      • Normally distributed
      • Stall dependent

Stall choices

Choice of stall is determined by a fixed “market share” concept. In other words, the choice of stall is akin to a multinomial distribution.

Conditions

Simulation created depicting this scenario runs on a set of conditions. Some are inferred or modified versions of the ones demonstrated in the scenario.

For each stall, the time taken by the customers to eat their food is generated from a Normal distribution

Customer Influx as a Poisson Process

A data collector’s account for the influx of customers from respective customer group size allocations presented composition data for a week between 12pm to 2pm. Corresponding group sizes were 1 - 8, and aside from those that wanted to dine in, there were also individuals that simply came into the shop for takeout/takeaway.

The composition of the customer base was noted. Similarly, the total number of customers that entered for the week per day, was noted. However, in the case of the simulation, a fixed number of customers was not set at the beginning to enter the shop and so forth. Instead, what was done was an emulation of 2 homogeneous Poisson process - one for each section of the peak hour (2/3 of the customers entering between the 60min period between 1215 and 1315, and the remaining 1/3 in the final 45min until 1400).

On Monday, 248 customers came in. On Tuesday, that was 206, and so on and so forth. The Poisson process, with the appropriate rate, can be used to approximately simulate a process whereby customers enter the foodcourt such that the total number of customers who visited the shop, is similar to that which was observed.

As stated in the data collection report, it was not entirely clear if all customers who wanted to come in, truly were able to come in, and purchase their desired products. There was an understanding that generally all customers that had entered the food court, were able to eventually get their food. In other words, there is no clear metric for the customers who were discouraged from entering the food court due to issues such as crowding.

A bold simplification | Difference between customers and customer groups

To simplify the process, a rate of 2.8 was estimated to be roughly appropriate for this simulation. This rate is not the true rate of customer groups coming. However, by virtue of the uncertainty involved in this case, it would seem reasonable to simply take the multinomial distribution of the group sizes at face value, and work backwards later to ascertain the rate of actual customer group influx.

If one were to take a genuine attempt at ascertaining the customer GROUP influx (in place of generic customer influx), one would incorporate a multinomial distribution into this simulation and attempt to work backwards.

The addendum

real<- function(cust_group_no){
  if (cust_group_no==0){
    return(0)
  }
  summie <- 0
  for (i in 1:cust_group_no){
    cv<-rmultinom(1,1,c(28,26,46,18,5,1,1,1,2))
    cvlist<-to_vec(for(i in 3:9) cv[i]*(i-1))
    summie<-summie+sum(cv[1:2],cvlist)
  }
  return(summie)
}

In the code, upon review, it has become clear that the applied rate of Customer generation, not to be confused with the individual customers, is meant to be approximately 1.2 - 1.5 as the base rate, followed by of course, the necessary, adjusted Customer influx rate.

As it is apparent above, the total number of customers generated here is a true reflection of the joint operation between the Poisson generation of the Customer group AND the multinomial distribution of the group size.

After allowing for queues in the shop, only 12 people are able to fit comfortably in the shop. This is presumed to indicate 2 things.

Firstly, there is an infinite possible length for queues if the situation called for it. This is an unrealistic assumption, yet given the circumstances is a consideration we are going to go forward with in our simulation.

Secondly, that there can be more than 12 people waiting inside the shop for tables, but this puts the shop in a state of overcrowding, which immediately disqualifies the shop from serving any new potential incoming customers who are not adopting the chope methodology, UNLESS these patrons are alone (take-away or dine in as 1).

Key Variables

Variables are required to depict each of the primary agents in this simulation.

Represents each customer GROUP (Customer) in the foodcourt. We can call this conceptualization, a “struct”.

Customers that have committed to eating at the foodcourt are designated a space in a Customer Vector, which is regularly updated in the time loop.

Number of customers, making up the group.

In the simulation, this is not entirely accurate. We do set values 1-8 to represent the number of customers directly, but we also incorporate the number ‘0’ to indicate customers that are only there for takeaway.

A boolean that denotes the customer’s behaviour: to chope or not to chope.

A boolean that denotes if the customer has COMPLETED queueing. It is important that this boolean does not update from its default FALSE state UNTIL the customer has already finished queueing

Similar boolean, to denote if customer has eaten or not.

This is a u32 variable that is regularly deducted in each iteration (whereby each iteration represents time). If this reaches 0, and other special circumstances are not a priority, the Customer’s status is typically updated from for example, having queued = FALSE to queued = TRUE, followed by calling a function for the Customer to allocate their eating time (that is rolled for at the inception of the Customer object being created) to the Current variable and to be counted down from. This situation would only be for a ‘chope’ Customer, since a Customer who was not choping would have to now wait for a table first. More importantly, this would also only apply for Customer that ARE NOT of group-size 0, in other words, takeaway customers.

Note that the non-choping customer’s “waiting for table” time, is NOT constant with time itself, whereas the eating time of every Customer is independent of time. You COULD conceivably call for a customer to specifically roll for their eating time WHEN they are at a table, however, in this simulation, we assume that eating time is not affected by other Customers (only customers within the group since we have to take the maximum eating time of the group).

Stalls chosen by each customer. This is an array of values stored and generated from to calculate, the Eating time, as well as tabulate the queueing time later on when relevant to the customer.

This is the total time the Customer has spent in the court, and is purely there for metric purposes.

Table array

A fixed array of 48 spaces. Initialized with values of 0, to represent unoccupied seats and they are updated with the occupying Customer’s eating time. Interested Customers do not occupy the table unless 2 conditions are fulfilled.

Firstly, the Waiting List for the Tables have to be empty.

Secondly, the tables have to have enough space for ALL the customers in the group to occupy.

Simple array in construction.

Waiting list

This is the other “struct” (complicated variable) aside from Customer. There are a number of defining features that explain this.

In fact, it is not even a struct, but a Vector of structs! The length of the waiting list is never constant and changes based off of the situation.

This is the group-size of the Customer that is waiting in line. Copied from the Customer occupying it.

Eating time for the Customer in this slot

The waiting time for a Customer in this slot is either calculated by comparing the Table array and calculating the wait time for enough spaces to be available, OR from the “Future Table” configuration of the predecessing Customer in the Waiting List.

The former happens if the Customer is the first and only one in the Waiting List, and the latter occurs in all other scenarios.

The configuration of the Table array when the Customer group moves in to finally occupy space in the Table array and eat.

Array of 5, recording the queue times of the 5 stalls.

Results

Simulations of these scenarios were repeated a number of times consecutively, and the indicative results were plotted as distributions.

Time distribution is referring to the total time spent by each customer in the court.

Sales refers to the total number of orders fulfilled by the end of each simulation.

Patrons refers to the total number of customers that invested their time into the foodcourt and entered with the purpose of dining in or purhchasing food from there.

Remaining Customers refers to the number of customers that remained in the food court by the end of the peak hour.

Waiting for table refers to the number of customers in the food court who were waiting for a table by the end of the peak hour.

Moving forward, tabs labeled with the *, indicate simulations for rates that were higher than reflected in the data collector’s numbers. The actual, more realistic depictions are for tabs that do not have that asterisk.

Remarks

By every measurable metric, it is apparent, that choping is efficient from a business and social standpoint!